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1.0 SUMMARY 

This note describes the processing of time In the Orbiter System Services soft- 
ware and the associated facilities provided to the user community. The descrip- 
tions are directed toward showing the functional intent of the design rather than 
the actual implementation. Simplified flow diagrams are included in Appendix A 
to enhance understanding of these time related functions. 

Based upon detailed analysis of a preliminary review copy of the Approach and 
Landing Test (ALT) System Software Detailed Design Specification (Reference A) 
and the Program Listings for Version 17 Prime (Reference B), the processing of 
time has the potential for error free operation. 

The processing of time is not expected to change between ALT and the Operational 
Flight Tests (OFT) other than differences in value of some constants for control 
and limit checking. 

Due to the dynamic nature of onboard time processing and its criticality to the 
successful operation of the Orbiter, it is recommended that a comprehensive 
list of external variables, their locations, initial values, and a "where used" 
listing be produced, as a by-product of the link edit process, for all non-HAL 
coding. In addition, a careful review of the verification test procedures for 
the System Services time-related software is recommended. 
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2.0 INTRODUCTION 

The Orbiter onboard processing of time and its use within the System Services 
software is not well understood by the engineering community outside of those 
individuals directly involved in the software development. This became evident 
when an issue arose regarding the Master Timing Unit (MTU) end of year rollover 
(reset of DAY counter to 1). Few of the engineers involved in that discussion 
understood that Greenwich Mean Time (GMT) was used as a basis for flight soft- 
ware interval time scheduling and that the rollover of time would produce a 
serious internal software time processing problem. This lack of understanding 
is largely due to the onboard processing of time being distributed over a number 
of subroutines and not being adequately described in consolidated documentation. 
This design note attempts to fill the need for a single document describing the 
functional intent of these time processes so that the engineering community 
may make more effective use of the time-related facilities provided by the 
System Services software. 
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3.0 DISCUSSION 

Time Is kept within each General Purpose Computer (GPC) to schedule events, to 
time tag events for downllst and/or logging, and to display "t1me“ on the Cathode 
Ray Tube (CRT) displays. Internal time (MY TIME) is used for these purposes. 

MY TIME Is periodically coordinated and corrected within the GPC cordon set (CS) 
by use of the MTU, or MY TIME of the Prime GPC (PRIME TIME). 

Three formats are used for time. The Flight Computer Operating System (FCOS) 
format is used for computation throughout System Services, the MTU format is 
used when interfacing with the MTU, and the floating point format is used when 
interfa g with applications programs. 

Time Ruling cf events or processes is accomplished by setting an interval 

time the difference between the present time and the desired time of 

exe» n. When the interval timer runs out, the event or process is dispatched. 

3.1 Ti me Sources 

MY TIME is the time base for the software system. Time continuity is maintained 
by using a coirenon time reference source to adjust MY TIf€ to agree with the 
common set selected time source. The preferred time reference source is the 
MTU. Next is PRIME TIME and finally MY TIME. The criteria for assessing 
acceptability of a time source is the absolute difference between the reference 
source and MY TIME being equal to or less than 580^ microseconds. 

The MTU is a line replaceable unit containing redundant master oscillators that 
step three accumulators for GMT and three for Mission Elapsed Time (MET). These 
accumulators keep ephemeris time and can be loaded and read by the GPC's. 


(1) 450 microseconds for OFT (recommended by IBM-see Reference C) 
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Although a set of MET accumulators Is provided in the MTU, these are not used 
to maintain MET for use by the flight software. Rather, an MET is synthesized 
In FCOS. However, the MTU MET accumulators do provide a direct MET cockpit 
time readout for OFT. 

Each of the MTU accumulator pairs (GMT/MET) are connected to a flight critical 
Multiplexer Demultiplexer (MDM). FCOS reads the MTU GMT accumulators during 
System Software Interface Processing (SSIP) common set synchronization. Process- 
ing of this time is called by System Control (SC) and is performed by the Time 
Redundancy Management function in FCOS. Each GMT accumulator is inspected in 
turn to find one that is acceptable. If no acceptable accumulator is found, 

PRIME TIME is tested. A default to MY TIME occurs if PRIME TIME fails the 
580^ microsecond test. The difference between the time of the selected source 
and MY TIME is then used to update MY TIME to agree with the source. 

3.2 GPC Time Formats 

Time is represented in the GPC's in FCOS, MTU, and floating point formats. The 
FCOS format consists of a full word (32 bits) that counts microseconds up to 
one half hour, and a half word that counts the number of elapsed half hours. 

This format (shown in Figure la) has a capacity in excess of 1365 days and is 
the format used for all System Services time manipulation. 


(1) 450 microseconds for OFT (recommended by IBM-see Reference C) 
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a. 


HALF HOUR MULTIPLE COUNTER 


FCOS TIME FORMAT 

• 16 BITS 

HALF HOURS 


HALF HOUR MICROSECOND COUNTER 


32 BITS 
MICROSECONDS 


b. MTU TIME FORMAT 


BIT POSITION 
FIRST WORD 


SECOND WORD 


THIRD WORD 


0 1 2 

3 4 5 6 

7 8 9 

10 11 

12 13 14 15 

1 DAY 1 

DAY j DAY j 

HR | 

HR I 

’ xlO 2 ; 

XI? ^ 

xlO° 1 

xlO 1 ' 

1A 0 * 
xlO 

| MIN. 

I MIN. 1 

SEC. 

SEC. 

IUNUSED | 

xlOl 

1 ,.10° 1 

xlO 1 

xlO 0 

1 ! 

1 UNUSED 

FRACTIONAL 
i SIGNIFICANT 

SECONDS 
BIT = 0 

III BINARY WITH LEAST 
.125 MILLISECONDS | 


c. FLOATING POINT TIME FORMAT 


EXP 


MANTISA 


1 BIT SIGN 

7 BITS HEXADECIMAL EXPONENT (EXCESS 64) 

56 BIT FRACTION - POSITIVE - HEXADECIMAL NORMALIZED 
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The MTU format, used to Interchange time with the MTU, contains ephemerls 
time in four bit Binary Coded Decimal (BCD) characters as shown In Figure lb. 

Note that the MTU steps In 125 microsecond Increments. 

The applications programs all use the floating point format. Time in this for- 
mat is in seconds as a double precision floating point number per Figure 1c. 

The capacity far exceeds that of the other formats { >10^ days while maintaining 
precision to one microsecond). 

3.3 System Services Time Keeping 

Two types of continuously incrementing time (MY TIME and interval time) are kept 
within the GPC as well as a reference time for MET =0. MY TIME is kept by a 
combination of a running counter. Program Counter 1 (PCI), and the Software 
Clock (SWC). The PCI is a combination of a 16 bit hardware register (least 
significant half) and a 16 bit core location (most significant half) forming a 
32 bit decrementing register. The counter is loaded with a binary number 
representing 2,097,151 and counts down at a rate of once per microsecond. When 
PCI is equal to zero, a PCI interrupt is issued to System Services. The counter 
continues to decrement so that the time lag in recognizing and processing the 

interrupt is not critical. When the PCI interrupt is processed, the binary value 
2.097,151 is added to PCI and also to the microsecond counter of the SUC. Since 

PCI continues to decrement into the negative region after the interrupt, arith- 
metically adding to PCI accounts for the time since the interrupt. The current 
value of MY TIME is calculated by adding the PCI elapsed time (2,097,151 - 
PCI value) to the SWC. Figure A-l depicts these processes. 

The interval timer. Program Counter 2 (PC2), operates similarly to PCI causing 
a PC2 interrupt when the counter reaches zero. There is no equivalent to the 
SWC for the interval timer because PC2 possesses adequate capacity (greater 
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than 71 minutes). PC2 Is used as an Interval timer to cause a process to be 
executed in a given number of microseconds from "now." 

System Services also maintains the time reference denoting MET Initialization 
(usually considered as the GMT of LIFT OFF). To initialize MET, MY TIME for 
the initializing event is computed and stored in "MET Reference Time" so that 
MET can be calculated at any future time by subtracting "MET Reference Time" 
from MY TIME. 

3 . * Z f mer Queue Element (TQE) Times 

The Timer Queue is a list of tasks to be performed at specific times. This 
list consists of entries called "elements" and is sorted into "time to execute" 
order. Three times are frequently encountered in examining the functions that 
reference the timer queue: "Last Expired TQE Time", "TQE Tine of Expiration", 

and "Top TQE Time of Expiration". 

The "Last Expired TQE Time" is the MY TIME when the last interval timer (PC2) 
interrupt occurred. This is the time that the last time-scheduled process was 
placed in "ready" status for execution. This time is important because it 
represents the time of initiation of the scheduled process and is used for all 
computations concerning the process. 

"TQE Time of Expiration" is the time at which a TQE is to place a referenced 
process into the active run queue for execution. The "Top TQE Time of Expirati 
is the "TQE Time of Expiration" corresponding to the top element in the active 
run queue, i.e. the element that is set to expire next. This will also be the 
element which PC2 is currently timing. The processing of TQE's is shown by 
Figure A-2. 
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3.5 Time Maintenance 

The following subsections discuss the major elements of time initialization, MTU 
updating, and time redundancy management. 

3.5.1 MY TIME Initialization 

When the first GPC is brought online by Initial Program Load (IPL), it sees no 
other members of the common set and will initialize MY TIME. An attempt is 
made to read the MTU and, if successful, this time is used to set the SWC after 
accounting for the value in PCI (i.e. PC'i is not reset but the value is used 
to bias the SWC to make MY TIME equal to the MTU time). 

As succeeding GPC's are brought into the common set, they will utilize PRIME TIME 
(MY TIME of the Prime GPC) to initialize their internal GMT clocks (their MY 
TIME). Figures A-3a and b show the flow for both of these processes. Note that 
if the Prime GPC designation shifts to a GPC coming into the common set, MY TIME 
of the incoming GPC will be initialized prior to the switching of PRIME desig- 
nation. 

3.5.2 MTU Update 

Updates can be initiated to bring the MTU into agreement with the ground processors 
and to synchronize the MTU-GMT and MY TIME. Provisions are available to reset 
and update the GMT and MET MTU accumulators. When an MTU update request is 
received, it is put into the MTU format and the Input/Output (I/O) operation 
is requested to perform an update. Updates to the MTU-liET accumulators also 
update the internal MET Reference Time, thus keeping these times in agreement. 

If the request is to synchronize the accumulators, the MTU-GMT is read and a 
zero delta update is formulated. If no MTU time is available, the update is 
formulated from PRIME TIME. Execution of either of these updates will set all 
GMT accumulators alike. Following the Queue of the I/O to update the MTU, 
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MY TIME is set to agree with fhe update time. Figure A-4 shows the flows for 
the MTU update functions. 

3.5.3 Time Redundancy Management 

Every eighteen^ minor cycles the MTU's are read during the normal SSIP pro- 
cessing. After the Intercomputer Communication (ICC) message exchange and the 
MTU "reads" are complete, the Time Redundancy Management function is executed. 

The MT'J times are compared, in turn, with MY TIME and are rejected as invalid 

(?) 

if v ey differ by more than 580 v 7 microseconds. If no valid MTU is found, 

PRIf.’t TIME is similarly tested and if that fails, internal time (MY TIME) is 
used. The selected source is flagged and MY TIME is adjusted to agree with 
the source, see Figure A-5. 

3.6 Time/Uate Tags for Applications Programs 

There are three times (Runtime, Clocktime, and MET) and one date that can be 
requested by applications programs using Supervisor Call (SVC) 22. The time 
request* produce double precision floating point numbers scaled in seconds 
and the date request produces two 16 bit values, years and days, "packed" in 
Application General Register 5. 

When "Runtime" is requested, the current MY TIME is calculated using the count 
in PCI and the value of the SWC. These results are then converted to seconds 
in double precision floating point format and left in the Floating Point General 
Registers 0 and 1 as expected by the HAL/S compiled application programs. 


(1) twenty four for OFT (recommended by IBM-see Reference C) 

(2) 450 microseconds OFT (recommended by IBM-see Reference C) 
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A "Clocktime" request produces a time similar to "Runtime" except the converted 
time is that of the last event or process initiated by the Interval timer, PC2. 

A request for "Mission Elapsed Time" converts "Clocktime" minus MET Reference 
Time to floating point. MET Reference Time would normally be the time of lift 
off. 

The "Date" request causes the program to calculate days into the mission then 
add the day and year of lift off. The year is placed in the upper (most 
significant) half of the Application General Register 5 and the day is placed 
in the lower half. Both of these numbers are fixed point binary integers. 
Figure A-6 shows the flow of these time and date functions supporting the FCOS/ 
HAL interface. 

An additional time tagging function is provided via SVC 32 which causes the 
"Last Expired TQE Time" to be converted to floating point and be stored in a 
specified location. The location in which to store the time is passed to the 
processing routine in the SVC parameter list. This function is shown in Figure 
A- 3c. 

Time tags are provided by System Services to display time in the upper right 
corner of the CRT displays. This time is MET as synth -ized by the System 
Services software in FCOS (may change to GMT for OFT). Time tags are provided 
in the fault messages from error processors that are displayed on the fault 
message line. The Cyclic Display processor provides conversion of the FCOS 
time format to display format in hours: minutes: seconds as required by the 
CRT display. In some cases the fault message comes from applications programs 
in floating point format. In these cases, the FCOS routine for conversion 
from floating point to FCOS format is used as a preprocessor for the display 
conversion. 
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4.0 CONCLUSION 

The time processing in System Services is distributed among assembly programs 
and procedures. Each of these stands alone when assembled and they are inter- 
related via the link editor. This causes many symbols to be related via the 
EXTERNAL reference which provides no interrelationship in the assembly listing. 

In addition, the REPLACE pseudo operator, especially when combined with the NO 
LIST operator, further subverts efforts to understand the code. Design docu- 
mentation and resulting code do not make it apparent that adequate interface 
control between System Services components and symbol name assignment control 
were established prior to the implementation phase of the design/development 
process. Coded adjustments to accommodate the resulting interfaces, variations 
in names used for the same parameters and the absence of control documentation 
are evidence that interface control was not systematically administered. These 
factors fragment time processing to a point where analysis is extremely difficult. 
This design note describes the functional intent of the design with the hope 
that it will be useful to those outside of the software development community. 

The research, performed in generating this paper, indicates a potential for 
trouble free time processing operation. 

It is recommended, in as much as interface control and symbol name documentation 
is unavailable, that a comprehensive list of external symbols, their locations, 
initial values, and a "where used" listing be produced as a by-product of the 
link edit process to aid in anomaly analysis. These data are presently 
produced for HAL symbols in the HAL STAT and should likewise be generated 
for symbols of the NON-HAL programs of System Services. In addition, the veri- 
fication test procedures should be reviewed for adequacy in testing the integrated 
performance of these time processing functions. 
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FIGURE A- 5 TIME REDUNDANCY MANAGEMENT FUNCTION 







